Romain Beauxis: When Rambo meets the Teletubbies..
Some recent discussions made me remember about this very nice trailer...
The interesting moment is at 01:45...
-w
option when connecting using SSH, and if you have the correct configuration, then two virtual network interfaces will be created on both the client and the server.
Using these interfaces with a bit of routing and resolving magic, you can establish a full connection tunneled through an SSH connection !
> I believe the issue is the one described in [3], but I couldn't find theGrmblf...
> corresponding commit on the svn. Well, then my work on hiding security critical commits in the cloud of other commits seems to have worked quite well. I guess that the pointers above should give you enough details to either find the appropriate fixes\reproduce them, or write your own patch.
The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.And here is what one of the devs from OSS answered to this [1]:
It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.
static inline short
bswap_16 (short x)
short y = 0;
unsigned char *a = ((unsigned char *) &x) + 1;
unsigned char *b = (unsigned char *) &y
*b++ = *a--;
*b++ = *a--;
return y;
unsigned char = one byte
, which seems reasonable. Then, a
is initialised at the second character of the two-characters value x
, and b
on the first of the returned (swapped) value y
. Now, the two cryptic lines can be decomposed as follows: *(b++) = *(a--)
, which literally means "put in b
the value from a
, and then increase b
and decrease a
. When executing the second line, a
points to the first character from x
, and b
to the second from y
. As Rupert noticed, the second call could simply have been *b = *a
, but this wouldn't have been l33t enough :) Now, about the original code, namely (x 8) (x >> 8)
, MadCoder (salut !), as well as another anonymous comment both suggested that this would be a type error. Indeed, I had noticed the wrong right shift, but no matter how I tried, with or without mask, with unsigned short
, short
, or uint16_t
, as suggested by MadCoder, I always get the same corrupted sound.. So, thanks for your comments, I'm now trying to dig the issue down in the code that makes use of this function. Most likely the issue comes from a wrong transtyping there.. I am also wondering what's the efficiency of the above OSS4's code with regard to (x 8) (x >> 8)
. Any idea ? PS: Yes, text on comments are mangled a lot. This is a basic safehtml protection, and I don't have the control over it, sorry..
((x) & 0x00ff) 8 ((x) & 0xff00) >> 8)
However, this is not working at all on my amd64/x86_64 box (core2duo CPU). I get a horrible saturated sound.. So, I copy-pasted this from oss4: static inline short
bswap_16 (short x)
short y = 0;
unsigned char *a = ((unsigned char *) &x) + 1;
unsigned char *b = (unsigned char *) &y
*b++ = *a--;
*b++ = *a--;
return y;
bswap_16
function included in byteswap.h
from libc6-dev
doesn't work either, and yields the same saturated sound..
Next.